这月绩效差点没了！搞了一个“新人拼团”活动遇到黑产，搭进去了8台服务器...

# 前言

最近，因为增加了一些风控措施，导致新人拼团订单接口的QPS、TPS下降了约5%~10%，这还了得！

首先，快速解释一下【新人拼团】活动：

业务简介：顾名思义，新人拼团是由新用户发起的拼团，如果拼团成功，系统会自动奖励新用户一张满15.1元减15的平台优惠券。这相当于是无门槛优惠了。每个用户仅有一次机会。新人拼团活动的最大目的主要是为了拉新。

新用户判断标准：是否有支付成功的订单 ? 不是新用户 : 是新用户。

# 问题分析

最近我们对在线同步这块的风控规则进行了加强和优化，导致整个新人拼团下单接口的执行链路更长，从而导致TPS和QPS这两个关键指标下降。

# 解决思路

要提升性能，最简单粗暴的方法是加服务器！然而，无脑加服务器无法展示出一个出色的程序员的能力。CTO说了，要加服务器可以，买服务器的钱从我工资里面扣……

在测试环境中，我们简单的通过使用StopWatch来简单分析，伪代码如下：

@Transactional(rollbackFor = Exception.class)
public CollageOrderResponseVO colleageOrder(CollageOrderRequestVO request) {
    StopWatch stopWatch = new StopWatch();

    stopWatch.start("调用风控系统接口");
    // 调用风控系统接口, http调用方式
    stopWatch.stop();
    
    stopWatch.start("获取拼团活动信息"); // 
    // 获取拼团活动基本信息. 查询缓存
    stopWatch.stop();

    stopWatch.start("获取用户基本信息");
    // 获取用户基本信息。http调用用户服务
    stopWatch.stop();

    stopWatch.start("判断是否是新用户");
    // 判断是否是新用户。查询订单数据库
    stopWatch.stop();

    stopWatch.start("生成订单并入库");
    // 生成订单并入库
    stopWatch.stop();
    
    // 打印task报告
    stopWatch.prettyPrint();

   // 发布订单创建成功事件并构建响应数据
    return new CollageOrderResponseVO();
}

执行结果如下：

StopWatch '新人拼团订单StopWatch': running time = 1195896800 ns
---------------------------------------------
ns         %     Task name
---------------------------------------------
014385000  021%  调用风控系统接口
010481800  010%  获取拼团活动信息
013989200  015%  获取用户基本信息
028314600  030%  判断是否是新用户
028726200  024%  生成订单并入库

在测试环境整个接口的执行时间在1.2s左右。其中最耗时的步骤是【判断是否是新用户】逻辑。这是我们重点优化的地方（实际上，也只能针对这点进行优化，因为其他步骤逻辑基本上无优化空间了）。

# 确定方案

在这个接口中，【判断是否是新用户】的标准是是用户是否有支付成功的订单。因此开发人员想当然的根据用户ID去订单数据库中查询。我们的订单主库的配置如下：

这配置还算豪华吧。然而随着业务的积累，订单主库的数据早就突破了千万级别了，虽然会定时迁移数据，然而订单量突破千万大关的周期越来越短……（分库分表方案是时候提上议程了，此次场景暂不讨论分库分表的内容）而用户ID虽然是索引，但毕竟不是唯一索引。因此查询效率相比于其他逻辑要更耗时。

通过简单分析可以知道，其实只需要知道这个用户是否有支付成功的订单，至于支付成功了几单我们并不关心。因此此场景显然适合使用redis的bitmap数据结构来解决。在支付成功方法的逻辑中，我们简单加一行代码来设置bitmap：

// 说明：key表示用户是否存在支付成功的订单标记
// userId是long类型
String key = "order:f:paysucc"; 
redisTemplate.opsForValue().setBit(key, userId, true);

通过这一番改造，在下单时【判断是否是新用户】的核心代码就不需要查库了，而是改为：

Boolean paySuccFlag = redisTemplate.opsForValue().getBit(key, userId);
if (paySuccFlag != null && paySuccFlag) {
    // 不是新用户,业务异常
}

修改之后，在测试环境的测试结果如下：

StopWatch '新人拼团订单StopWatch': running time = 82207200 ns
---------------------------------------------
ns         %     Task name
---------------------------------------------
014113100  017%  调用风控系统接口
010193800  012%  获取拼团活动信息
013965900  017%  获取用户基本信息
014532800  018%  判断是否是新用户
029401600  036%  生成订单并入库

测试环境下单时间变成了0.82s，主要性能损耗在生成订单入库步骤，这里涉及到事务和数据库插入数据，因此是合理的。接口响应时长缩短了31%！相比生产环境的性能效果更明显……接着舞！

# 晴天霹雳

这次的优化效果十分明显，想着CTO该给我加点绩效了吧，不然我工资要被扣完了呀~

一边这样想着，一边准备生产环境灰度发布。发完版之后，准备来个葛优躺好好休息一下，等着测试妹子验证完就下班走人。然而在我躺下不到1分钟的时间，测试妹子过来紧张的跟我说：“接口报错了，你快看看！”What?

当我打开日志一看，立马傻眼了。报错日志如下：

io.lettuce.core.RedisCommandExecutionException: ERR bit offset is not an integer or out of range
at io.lettuce.core.ExceptionFactory.createExecutionException(ExceptionFactory.java:135) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.ExceptionFactory.createExecutionException(ExceptionFactory.java:108) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.AsyncCommand.completeResult(AsyncCommand.java:120) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.AsyncCommand.complete(AsyncCommand.java:111) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.CommandHandler.complete(CommandHandler.java:654) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:614) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
…………

bit offset is not an integer or out of range。这个错误提示已经很明显：我们的offset参数out of range。为什么会这样呢？我不禁开始思索起来：redis bitmap的底层数据结构实际上是string类型，redis对于string类型有最大值限制不得超过512M，即2^32次方byte…………我靠！！！

# 恍然大悟

由于测试环境历史原因，userId的长度都是8位的，最大值99999999，假设offset就取这个最大值。那么在bitmap中，bitarray=999999999=2^29byte。因此setbit没有报错。

而生产环境的userId，经过排查发现用户中心生成ID的规则变了，导致以前很老的用户的id长度是8位的，新注册的用户id都是18位的。以测试妹子的账号id为例：652024209997893632 = 2^59byte，这显然超出了redis的最大值要求。不报错才怪！

紧急回退版本，灰度发布失败~还好，CTO念我不知道以前的这些业务规则，放了我一马~该死，还想着加绩效，没有扣绩效就是万幸的了！

本次事件暴露出几个非常值得注意的问题，值得反思：

• 懂技术体系，还要懂业务体系

  
  对于bitmap的使用，我们是非常熟悉的，对于多数高级开发人员而言，他们的技术水平也不差，但是因为不同业务体系的变迁而无法评估出精准的影响范围，导致无形的安全隐患。本次事件就是因为没有了解到用户中心的ID规则变化以及为什么要变化从而导致问题发生。

• 预生产环境的必要性和重要性

  
  导致本次问题的另一个原因，就是因为没有预生产环境，导致无法真正模拟生产环境的真实场景，如果能有预生产环境，那么至少可以拥有生产环境的基础数据：用户数据、活动数据等。很大程度上能够提前暴露问题并解决。从而提升正式环境发版的效率和质量。

• 敬畏心

  
  要知道，对于一个大型的项目而言，任何一行代码其背后都有其存在的价值：正所谓存在即合理。别人不会无缘无故这样写。如果你觉得不合理，那么需要通过充分的调研和了解，确定每一个参数背后的意义和设计变更等。以尽可能降低犯错的几率。

# 后记

通过此次事件，本来想着优化能够提升接口效率，从而不需要加服务器。这下好了，不仅生产环境要加1台服务器以临时解决性能指标不达标的问题，还要另外加7台服务器用于预生产环境的搭建！因为bitmap，搭进去了8台服务器。痛并值得。接着奏乐，接着舞~~~

来源：https://juejin.im/post/6854573218322513933

 往期推荐 

🔗

 

点击阅读原文，获得免费编程视频资料！